Day 5 - 用 Skill 把競品頁面拆成功能、流程與假設

為什麼不能直接抄競品？

很多人看見別人的App長得好看、按鈕很好用，就直接叫工程師照抄。但這就像在路上看到別人開跑車，你只學外觀做了一台模型車，卻不知道引擎在哪裡。

FlowBoard 模擬競品截圖

今天把昨天最小觀察資料直接放在這裡。
把一張競品截圖拆成三個不能混為一談的東西：功能、流程與假設。
讀表時，先把「畫面上真的看得到的東西」和「點擊後可能發生的事」分開：

接下來的 F1、P1、H1 都會回到這三個編號。

為什麼不能把功能、流程與假設混在一起？

讀截圖時，先把「畫面上看得到的東西」和「點擊後發生的事」分開：

• 功能：車子的方向盤（產品能提供什麼能力）。

• 流程：開車的步驟（使用者怎麼一步步完成任務）。

• 假設：我覺得駕駛現在想去加油站（團隊對使用者需求的暫時猜測）。

如果把它們混在一起，團隊就會做出錯誤的產品。

建立可追溯的拆解表

拆解時，要嚴格遵守以下規則：

① 功能用動詞描述：例如「查看分派任務」。
② 流程寫出實際動作：如果點擊後看不到下一頁，就要老實寫「截圖無法確認」，絕不腦補。
③ 假設寫出前提：必須能寫成「如果……那麼……」並找出反例。

每寫一條，都要綁定畫面上的證據編號。這能防止 AI 把猜測當成事實。

讓 AI 執行拆解

背景：
研究題目是專案協作產品的新成員啟用。輸入來自單張頁面截圖。

任務：
1. 從觀察表辨識畫面提供的功能。
2. 只用可見元素排列「已知步驟」；缺少的步驟標記未知。
3. 提出支撐此設計的候選假設。
4. 為每個假設設計最低成本的驗證問題。

輸入：
【Day 4 元素觀察表】

限制：
- 不加入截圖外功能。
- 不把元素、功能、流程與假設混用。
- 每列保留元素編號。
- 若流程終點看不到，寫「截圖無法確認」。

輸出：
A. 功能表：編號、功能、使用者可能完成的事、證據
B. 流程表：步驟、動作、畫面回饋、確定程度
C. 假設表：假設、依據、替代解釋、驗證方式

範例輸出

已知流程
1. 新成員位於歡迎頁（E1）
2. 可選擇「查看分派給我的任務」（E2）
3. 點擊後狀態：截圖無法確認

候選假設 H1
假設：部分新成員加入時已有被指派任務。
依據：E2 被放在第一張卡片並使用實心按鈕。
替代解釋：排序可能只是版面預設。
驗證：檢查新成員首次登入時已有指派任務的比例。

這比「競品有 onboarding checklist」更有用，因為它指出方案可能成立的前提。

套回 FlowBoard

FlowBoard 目前只有模擬客服回饋，尚不知道新成員登入時是否已有任務。因此，不能直接照搬 E2。團隊可以先列兩條分支：

這時競品分析開始產生價值：幫我們看見原本漏掉的狀態。

如果能操作該公開產品，可在有權限的範圍內補第二張「點擊後」截圖，並另編元素編號。這會增加流程證據，但依然不能證明設計成效。若不能操作，就讓未知保持未知；清楚的缺口比虛構的完整流程更能幫助決策。

人類需要檢查什麼

• 這真的是畫面可提供的能力嗎？
• 流程是否跨越了看不到的頁面？
• 假設是否可以被證偽？
• 驗證資料是否取得得到？若答案是否定的，就降低確定程度或刪除。

產品團隊還要確認觀察對象與 FlowBoard 是否具可比性。目標使用者、團隊規模與權限模型不同，都可能讓相似 UI 解決不同問題。

最後請一位沒有參與截圖分析的同事閱讀表格，遮住假設欄，只看證據是否能重建功能與已知流程。若無法重建，通常是元素編號不足、動作寫得太抽象，或流程跨過了截圖沒有呈現的狀態。先修正證據層，再討論產品含義。

今天的產出物

今天完成的是競品功能拆解表，包含功能、已知流程、候選假設、證據編號及未知處。

明天將比較這些候選假設與 FlowBoard 情境卡，找出值得驗證的產品機會。機會不會寫成「複製三張卡片」，而會寫成使用者、問題、價值與驗證方式。

把拆解表封裝成 Claude Code Skill

沿用 Day 4 的觀察檔，建立：

.claude/skills/competitor-breakdown/SKILL.md

---
name: competitor-breakdown
description: 將競品畫面觀察拆成功能、流程與假設，保留每一列的證據編號與未知項。
---

輸出表格欄位：編號、類型、描述、證據、未知。
功能用可執行動詞；流程用有順序的動作；假設用「如果……那麼……」。
不能把假設改寫成競品事實，也不能補出截圖看不到的點擊後頁面。

執行：

/competitor-breakdown 請讀取此圖的觀察，建立功能、流程、假設三欄表。

輸入觀察編號，輸出是一張同時容納功能、流程與假設的表，每一列都掛著來源元素編號與未知項：

今天的產出物

今天完成的是競品功能拆解表。

清楚的缺口（未知），會比虛構的完整答案更能幫助團隊做決策。明天將利用這張表，找出真正值得驗證的產品機會。

參考資料

• GOV.UK Service Manual：Analyse a research session